Subject: Re: DLSW Queries

From: Future1 <[email-masked]>
Date: Mon, 29 Jan 96 07:37 EST

Hi Gayek,

Thanks for response and the info regarding scalability. We 
have some more queries regarding RFC 1795.

1. Does a 1434+ implementation mean conforming to drafts 
released between RFC 1434 and RFC 1795 ?

2. If the answer to 1 is "Yes" then these drafts (June 1994,
August 1994, etc) suggest a CAPEX negotiation. In this 
case how do we differentiate between 1434+ and 1795 
partner(since in both cases dlswTConnOperPartnerVersion 
object will be updated after reception of CAPEX request)?

3. If the answer to 1 is "No", then can we assume that it 
will be the same as 1434 implementation with 
ENTER BUSY/EXIT BUSY flow control mechanism ? 

4. If the answer to 1 is "Yes" then these drafts (June 1994,
August 1994, etc)suggest that a 1434+ can follow any one of
the following mechanisms. Fixed pacing, Adaptive pacing or
Enter Busy/Exit busy. In this case, how do we identify the 
kind of flow control mechanism adopted by a 1434+ partner?

5. In a scenario where 1795 DLSw is following Adaptive 
Pacing communicates with 1795 DLSw following fixed Pacing, 
how does the node following Adaptive Pacing know that the 
partner is following Fixed pacing, so as to avoid sending 
of Increment or Decrement window operators to the partner
DLSw?

6. If Negative CAPEX response is received for a previously 
sent CAPEX request, what is the corrective action that is 
to be taken?

7. If the MAC address list Control vector(in CAPEX) 
specifies a MAC address which is present in local MAC cache
(dynamically learnt)indicating location as local, which one 
should be considered as valid?

8. How do we resolve reception of CANUREACH_ex from opposite 
direction in SENT_EX state?

9. What is the significance of using MAC address as criteria 
in resolving opposite direction CANUREACH_cs in CIRCUIT_START 
state ?

10. Can the reception of a increment or decrement window
operator while operating in fixed pacing mode, be considered 
as a Protocol Violation ?

With Best Regards,
>From Sivakumar G, Future Software.

Sivakumar G,
Future Software Pvt. Ltd.
E-mail : [email-masked]
Phone  : +91-44-4342166
Fax    : +91-44-4344157

---

From: [email-masked] (Alan Bartky)
Date: Mon, 29 Jan 96 08:55:09 PST

Sivakumar G -

Sorry that I can't update you on specifics of DLSw as I don't
have time to go through it (and it would be better if someone 
who actually implemented it commented on the protocol specific
functions as I was busy enough as editor just doing cut and
paste of all the submissions I received).

I can update you (and hopefully others who did not
directly participate in DLSw working group)
on your version questions on rfc1434, rfc1434+,
intermediate draft versions, and rfc1795 (a.k.a. DLSw standard
version 1.0).

> released between RFC 1434 and RFC 1795 ?

NO!  1434+ was the name given by IBM for their version of
the protocol used by the 6611 routers which added some
changes to the SSP protocol after the publication of the
informational RFC1434.  The major change of interest is
the ENTER_BUSY, and EXIT_BUSY flow control messages.

When the DLSw working group was formed in the AIW, one of
the goals we had was to improve the protocol and to make
sure the next version would be fully documented as far
as messages and state machines.

The drafts edited by myself during the days of working on
the new DLSw specification, are DRAFTS!  There are no
implementations existing (to my knowledge) that are deployed.
The goal of the group was to write and implement a protocol
that everybody agreed to.

After much discussion, it was agreed that we would not
discuss, figure out, or document how an rfc1434 (or rfc1434+)
implementation would interoperate with a DLSw Standard 1.0
implementation.  It was too much work to take on and also
would degrade the goal of having one version of DLSw that
everyone could use and interoperate with.

If you really need to get the differences between rfc1434 and
rfc1434+, it is available somewhere on the IBM FTP server.
Sorry I don't have the filename and location, that email
file is back at my old job at Sync Research (maybe someone
on the DLSw mailer will see this and give this information).

> object will be updated after reception of CAPEX request)?

1434+ does not have CAPEX negotiation (even this is documented
in RFC1795).  The drafts are just drafts, nothing more.
 
> ENTER BUSY/EXIT BUSY flow control mechanism ? 

An implementation (if they still exist) of RFC1434 would
not have enter and exit busy messages.  RFC1434+ implementations
(which again I have no idea how many are out there)
do have them.  In fact that was one of the problems we discussed
that definetly affected interoperability.  There was no
way that one could tell the difference between an RFC1434 or
an RFC1434+ implementation on the other end, so you couldn't
know if you could send enter or exit busy to the other device
(unless you figured it out once you received an enter/exit
busy from the other side).

> kind of flow control mechanism adopted by a 1434+ partner?

We got rid of support for all of the other mechanisms in the final
version since it was decided that all implementations of the
new DLSw standard should use one and only one version of
flow control/pacing.  Adaptive pacing was chosen as the method
to use and all other methods (enter/exit busy and fixed pacing)
were dropped.

A 1434+ implementation only has Enter/Exit busy (no fixed
or adaptive pacing).
 
> of Increment or Decrement window operators to the partner

Fixed pacing was dropped and is not supported.  You would
save yourself and ourselves a lot of time if you went
out and burned all of the draft copies you currently have.

(Peter, maybe you should delete them from the FTP server).

For questions 6 through 9, you'll have to get an
answer from someone else.  I don't have the time to do
research on them and can't answer them from memory.

> as a Protocol Violation ?

THERE IS NO FIXED PACING!

> E-mail : [email-masked]
I hope the answers on the history of drafting DLSw Version 1.0
and the other information contained herein are usefull to you.

Regards,

Alan (editor of DLSw Standard version 1.0, RFC1795)

**********************************************************
Alan K. Bartky                       Email:[email-masked]
Principal Software Engineer
XYLAN Corporation                    Voice:(714) 597-8042
15707 ROCKFIELD BLVD STE 155F        FAX:  (714) 597-8342
IRVINE CA 92718-2830
**********************************************************

---

From: "Peter W. Gayek" <[email-masked]>
Date: Mon, 5 Feb 96 14:20:35 EST

Sivakumar G -
I'm sorry for the delay in responding to your questions.  Alan and
Isabelle have handled some of the key ones.  I would just add the
following comments to Alan's latest append:

- Alan is right that RFC1434+ was just a name for the 6611 level
  barely past RFC1434, so it does not imply capex or pacing at all.
  By agreement of the vendors who implemented 1434 at the time
  (Proteon, IBM, Bay), it meant you needed to be able to receive
  ENTER_BUSY and EXIT_BUSY and act appropriately, but you didn't
  have to send them if you didn't want to.  Since Proteon and Bay
  both wanted 6611 interoperability, the problem Alan mentioned
  about distinguishing 1434 and 1434+ never occurred in the real world.

- As Isabelle and Alan have said, RFC 1795 requires support of
  adaptive pacing as a sender but not as a receiver.  So as a
  receiver, one's implementation may in fact (only) do fixed pacing.
  Both roles are independent, of course.

- Alan, I don't control the files at the FTP server but I agree
  we could get rid of the old drafts.  Maybe there could be a 2-minute
  agenda item at the next AIW to all approve which files to delete.

>sent CAPEX request, what is the corrective action that is

See the minutes of the last AIW, where this was an active topic of
discussion.  I think the outcome was that for initial capex, the
receiver of a negative response is to take down the TCP connection
and not try forever.

>should be considered as valid?

I feel this is a product design question that is outside the
scope of the architecture.

>direction in SENT_EX state?

I don't see that there's anything to resolve - I think you
would handle CUR_ex the same way you normally do.  I view
crossing *_ex exchanges as unrelated to each other since neither
is an attempt to set up a circuit.

>in resolving opposite direction CANUREACH_cs in CIRCUIT_START

We needed something to compare so both sides would deterministically
reach the same decision about which direction would succeed and
which would fail.  Comparing MAC addresses is independent of
transport type, while comparing IP addresses (another proposal
once discussed) is not, so the RIG picked that as a good test.

>as a Protocol Violation ?

Absolutely not.  You are required to support adaptive pacing as
a sender, which means you must obey all increment and decrement
window operators from the other side.  If you implemented a
product option to do only fixed pacing as a sender, you would
be out of compliance with the RFC when operating in that mode.

>E-mail : [email-masked]

Peter Gayek
IBM Corp.